…urns at end-of-Run (Codex P1 #32, P2 #33)

P1 #32: my round-7 wiring nulled \`_fileCheckpointer\` in
\`Graph.clearHeavyState\` — but \`Run.processStream()\` calls
\`clearHeavyState\` in its finally block on natural-completion AND
error paths, exactly when the host most needs to call
\`Run.rewindFiles()\` for rollback. The fix:

  1. Drop the \`this._fileCheckpointer = undefined\` line. Per-Run
     isolation is automatic because each \`Run.create()\` constructs
     a brand-new Graph instance.

  2. Update \`getOrCreateFileCheckpointer\` to return the cached
     instance unconditionally if present. Without this, the
     toolExecution-engine guard inside the accessor would reject
     the cached checkpointer once \`clearHeavyState\` nulled
     toolExecution.

P2 #33: the \`directPathTurns\` map I added in #30 to make
direct-path turns resume-stable was never cleared, so it grew
linearly with tool calls AND would have returned stale slots if a
provider reused call IDs across turns. Added:

  - \`ToolNode.clearDirectPathTurns()\` public method (\`@internal\`
    by convention but exposed for hosts that reuse a ToolNode
    outside a Graph).

  - \`Graph._compiledToolNodes\` set populated via
    \`registerCompiledToolNode()\` from each
    \`StandardGraph.initializeTools\` ToolNode construction site.

  - \`clearHeavyState\` iterates the set and calls
    \`clearDirectPathTurns()\` on each, then drops the set itself.

End-of-Run is the right boundary: directPathTurns is used during
hook lifecycle / runTool execution, never read post-run, so
clearing it there doesn't conflict with the checkpointer's
opposite requirement (which now survives clearHeavyState).

Tests pinned: \`checkpointer survives Graph.clearHeavyState so
post-completion rewind works (Codex P1 #32)\` exercises the round-
trip through the same cleanup the host hits, and
\`clearDirectPathTurns() empties the per-Run cache (Codex P2 #33)\`
pins the method directly. 808 tests passing across all suites.